💡 什麼是跨站請求偽造（CSRF）？
在了解了越權與設定不當後，今天我們來探討另一個常讓人與 XSS 搞混、但攻擊手法完全不同的經典 Web 漏洞——A03 跨站請求偽造（Cross-Site Request Forgery, 簡稱 CSRF 或 XSRF）。

如果說 XSS 是利用「受害者信任惡意網站」來偷取資料，那麼 CSRF 就是利用「目標網站信任受害者的瀏覽器」來發動攻擊。
在 CSRF 攻擊中，攻擊者會誘騙受害者進入一個惡意網站，該網站會暗中強迫受害者的瀏覽器，向一個受害者已經登入的「受信任網站（例如銀行、論壇或購物平台）」發送惡意請求。因為瀏覽器會自動帶上該網站的 Cookie（Session），導致伺服器誤以為這個請求完全是使用者本人自願發出的！

🔍 CSRF 的攻擊運作情境
想像以下經典情境：

正常登入： 使用者登入了某個線上銀行網站 bank.com，此時瀏覽器儲存了該銀行的登入憑證（Session Cookie）。

誤觸陷阱： 使用者在未登出銀行的情況下，點擊了一個釣魚郵件或瀏覽了惡意論壇 evil.com。

自動發包： evil.com 的網頁中藏有一段隱蔽的自動提交表單或圖片標籤，內容如下：

HTML

🛠️ CSRF 與 XSS 的關鍵差異
許多新手常分不清 XSS 與 CSRF，我們可以透過以下特點快速辨識：

XSS（跨站腳本）： 攻擊者能夠「讀取」受害者的 Cookie 或在受害者瀏覽器中執行任意 JavaScript 程式碼。

CSRF（跨站請求偽造）： 攻擊者「無法讀取」受害者的 Cookie 內容，他只是借用受害者的身份去「發送非預期的請求」（就像拿著你掉在地上的悠遊卡去刷卡，但卡片本身在你自己手裡）。

🛡️ 如何有效防禦 CSRF 攻擊？
現代 Web 開發框架通常已內建防禦機制，常見的防禦手法包含：

Anti-CSRF Token（權杖機制）：
伺服器在生成表單時，會隨機產生一串獨一無二且不可預測的 Token 放在表單與 Session 中。當使用者提交表單時，伺服器必須核對該 Token 是否相符。因為惡意網站無法跨域讀取或猜測這串 Token，攻擊自然會失敗。

Cookie SameSite 屬性設定：
在設置 Cookie 時加上 SameSite=Strict 或 SameSite=Lax 標籤。這能限制瀏覽器在「跨站請求（Cross-Site）」時自動帶上 Cookie，是目前阻擋 CSRF 最有效且簡便的瀏覽器層級防禦。

重要操作要求二次驗證：
針對密碼修改、資金轉帳等敏感操作，要求使用者手動輸入舊密碼或驗證碼（OTP），從根本上防止自動化偽造請求。